CAS协议是一个简单且十分强大的基于票据管理的CAS专用协议，协议详细文档请移步http://jasig.github.io/cas/4.1.x/protocol/CAS-Protocol-Specification.html
该协议中涉及到一个或多个CAS客户端和服务端的交互，客户端嵌入了CAS的类库，而CAS服务端则是一个独立的应用程序。CAS服务端负责用户的认证和授予访问权限给访问请求。CAS客户端负责保护应用程序和接收CAS服务端对用户的认证数据。交互过程主要涉及到概念有：
- TGT（Ticket Granting Ticket），存储在名为CASTGC的cookie中，代表一个用户的单点登录session
- ST（Service Ticket）,作为Http的GET请求的一个参数在URL中传递，代表了CAS针对某个特定用户授予了准予访问的权限
一般认证流程：
目前最新的CAS协议版本为3.0，最新的版本草案也将实现代码放在CAS的代码库中，作为对2.0版本最常见问题的修复和增强，在3.0所有新增功能点中，最引人注目的就是3.0中增加了通过新链接/p3/serviceValidate返回认证/用户属性的功能。
根据上述流程简述CAS认证过程。假定cas服务器的地址是：http://cas.service.com，web应用的地址是：http://web1.service.com。
- 用户浏览器访问http://web1.service.com/。
- web1让用户浏览器去访问cas服务器的登录URL，并带上自己的处理登录请求的URL。在cas中，这个URL叫做service。如：http://cas.service.com/login?service=http://web1.service.com/caslogin请注意：http://cas.service.com/login是cas服务器处理用户登录的URL。service=http://web1.service.com/caslogin是传递给cas服务器的参数，告诉服务器现在是http://web1.service.com/caslogin在请求登录。注意这里为了方便查看和理解，没有对service=后面的URL进行URL编码。在实际环境中，这个URL是需要进行URL编码的。
- cas对用户进行验证。如果用户没有登录cas，则出现一个登录界面，让用户输入用户名和密码进行登录。登录成功时，cas服务器会在用户浏览器中放置一个cookie(CAS中简称之为CASTGC)，这个cookie在浏览器关闭以后就会失效。如果用户浏览器不接受cookie，则不能保持登录状态。
- 完成登录以后，cas服务器会把用户浏览器转向到service的URL，同时提供一个ticket，如http://web1.service.com/caslogin?ticket=ST-29-pZvV4kcz5z0TaQxiCVf0。这个ticket称为service ticket。
- Web1接到用户的请求并获取service ticket以后，将会到cas服务器去验证service ticket的有效性。此时web1会访问cas服务器的验证地址http://cas.service.com/serviceValidate?service=http://web1.service.com/caslogin&ticket=ST-29-pZvV4kcz5z0TaQxiCVf0,这里带两个参数：service ticket和service 注意这里是web1直接访问cas服务器去验证。
- cas服务器会验证ticket的有效性，然后给出验证结果 Web1根据cas服务器给出的结果判断是否允许用户登录。
代理认证流程：
代理认证主要针对应用1跳转到应用2时可以简化访问的步骤，若不使用代理认证，需要进行多次重定向而使用代理认证应用1获取到代理票据以后即可跳转到应用2
- 1.用户浏览器访问http://web1.example.com/。
- 2.web1让用户浏览器去访问cas服务器的登录URL，并带上自己的处理登录请求的URL。在cas中，这个URL叫做service。如：http ://cas.example.com/login?service=http://web1.example.com/caslogin。请注意：http://cas.example.com/login是cas服务器处理用户登录的URL。service=http://web1.example.com/caslogin是传递给cas服务器的参数，告诉服务器现在是http://web1.example.com/caslogin在请求登录。注意这里为了方便查看和理解，没有对service=后面的URL进行URL编码。在实际环境中，这个URL是需要进行URL编码的。
- 3.cas对用户进行验证。如果用户没有登录cas，则出现一个登录界面，让用户输入用户名和密码进行登录。登录成功时，cas服务器会在用户浏览器中放置一个cookie，这个cookie在浏览器关闭以后就会失效。如果用户浏览器不接受cookie，则不能保持登录状态。
- 4.完成登录以后，cas服务器会把用户浏览器转向到service的URL，同时提供一个ticket，如http: //web1.example.com/caslogin?ticket=ST-29-pZvV4kcz5z0TaQxiCVf0。这个ticket称为service ticket，简称ST。
- 5.Web1接到用户的请求，获取ST以后，到cas服务器去验证ST的有效性。此时web1会直接访问cas服务器的验证地址：http://cas.example.com/serviceValidate?service=http://web1.example.com/caslogin&ticket= ST-29- pZvV4kcz5z0TaQxiCVf0&pgtUrl=http://web1.example.com/casProxyCallBackURL。在验证ST时，附加参数：pgtUrl，这是一个proxy callback url，告诉CAS服务器本次调用希望用此url获得proxy granting ticket。
- 6.cas服务器会验证ticket的有效性，然后给出验证结果。Web1根据cas服务器给出的结果判断是否允许用户登录。在CAS1.0协议中，cas只需要告诉web1这个ST代表的用户ID即可。在2.0中，CAS服务器在检测到pgtUrl这个参数时，会多做两件事：
- 7.在验证结果中给出proxyGrantingTicket IOU，简称PGTIOU（proxyGrantingTicket简称PGT）。PGTIOU是一个字符串，CAS中解释为PGT的索引，不是PGT本身。
CAS服务器会向pgtUrl指定的地址发送PGT和PGTIOU。PGT一次申请，多次使用。生存期为web1与cas当前的session，TGT有效期？
前面的过程，与CAS1.0中的认证过程基本一致，除了最后两步。接下来，假定web1是门户，现在web1需要访问邮件系统中用户的邮件数据。假定邮件系统给出的代理认证的url地址是：http://email.example.com/casProxyLogin。 - 8.Web1向CAS服务器发起代理认证的请求：https://cas.example.com/proxy?pgt=proxyGrantingTicket&targetService=http://email.example.com/casProxyLogin
请求的参数是 pgt和targetService。CAS服务器对pgt进行认证，如果是有效的pgt，则返回一个proxyTicket(简称PT)给web1。 - 9.Web1访问http://email.example.com/casProxyLogin，并提供PT。
- 10.Email服务器到CAS服务器上验证PT的有效性，访问：https://cas.example.com/proxyValidate?ticket=proxyTicket&service=http://email.example.com/casProxyLogin
- 11.CAS服务器验证ticket和service的有效性。当发现ticket是proxyTicket时，返回用户ID，一个CAS服务器颁发给email服务器的PGT，同时返回一个proxy的列表。在此例中，proxy列表只含有一个proxy，即http://web1.example.com/casProxyCallBackURL，也就是前面提到的pgtUrl。email服务器可以根据这些所有的信息，决定是否让用户登录。
关于proxy列表：Proxy列表列出了此代理链中所有代理应用的pgtUrl。并且，最近的proxy列在最前面。
如果email服务器再代理登录到第三个应用，如:http://web3.example.com/casProxyLogin3，则此时的proxy列表有两个proxy，顺序如下：